POV-Ray : Newsgroups : povray.beta-test : v3.7 example scenes : Re: v3.7 example scenes Server Time
28 Jul 2024 22:15:51 EDT (-0400)
  Re: v3.7 example scenes  
From: Chris Cason
Date: 23 Sep 2008 00:47:53
Message: <48d874f9$1@news.povray.org>
Jim Holsenback wrote:
> I still have modified scenes on my system and it (woodbox.pov) looks like 
> it's been done on my end. I connected to the ftp site and in 
> jim/scenes/advanced woodbox.pov has been changed as well.

You are correct; it appears the updated installer I made had the old
file in it for some reason. Apologies for getting it wrong.

> Perhaps I jumped the gun abit. Things were flying pretty fast and when I 
> floated the idea of addressing this issue it didn't seem that anyone had any 
> strong feelings one way or another, so I pulled the trigger. If I could have 
> a few days to think about how to address this to everyones satisfaction I'd 

Sure, feel free to think it over. I think we need to move forward on
stuff like this without the fear of being bound to the past, while at
the same time keeping in mind that one of the impediments to upgrading
any software is if a user's old files don't work (properly). Hence we
need to balance things and provide backwards compatibility where possible.

If (as it appears to be the case) the SDL as it stands doesn't provide
a clean way of deprecating existing constructs while still permitting
their use, then we need to enhance the SDL. I'm inclined to add such a
means. For example:

  #declare I_Glass4=
    deprecated once "... some message goes here ..."
    interior {
      ior 1.5
      fade_distance 2.0
      fade_power 1001
    }

if we did it this way, for example, the #declared item is known by the
parser to be deprecated: this generates no warning during the parse of
the #declare itself (or even if the #declare is used in another
#declare), but if it is used in an actual object, the message
associated with it is displayed (if the 'once' keyword is present,
it's only displayed once per parse, otherwise it's displayed each time
it's used in an object).

I'm not saying it has to be done this way; it's just one thing that
comes to mind. It would require the parser to track the deprecated
status of each #declared item (passing up the state if a new declare
inherits a deprecated declare, and so forth), which isn't as clean as
I'd like it to be. The other option is to display the warning anytime
the declare is used (even if in another declare, which means we have
to ensure we don't use such declares as part of something else in the
same standard include file as this would trigger the warning even if
the end-user didn't use the #declared item).

-- Chris


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.